Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standardizing First Party Data #4472

Merged
merged 52 commits into from
Feb 19, 2020

Conversation

msm0504
Copy link
Contributor

@msm0504 msm0504 commented Nov 15, 2019

Type of change

  • Bugfix
  • Feature
  • New bidder adapter
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Does this change affect user-facing APIs or examples documented on http://prebid.org?
  • Other

Description of change

Use fpd.user and fpd.context objects from config to get first party data within Rubicon and Prebid Server bid adapters

Data format from Solution Proposal #3687

nakamoto and others added 30 commits February 16, 2019 21:30
# Conflicts:
#	modules/advangelistsBidAdapter.js
#	test/spec/modules/advangelistsBidAdapter_spec.js
@stale
Copy link

stale bot commented Dec 30, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Dec 30, 2019
@msm0504 msm0504 removed the stale label Jan 2, 2020
@stale
Copy link

stale bot commented Jan 13, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 13, 2020
@bretg bretg removed the stale label Jan 14, 2020
@bretg bretg requested a review from snapwich January 23, 2020 01:33
@bretg
Copy link
Collaborator

bretg commented Jan 23, 2020

Ok, let's see if we can drive this home.

@msm0504 - does this pbsBidAdapter code handle ext.prebid.bidderconfig as discussed in
#3687 (comment) ?

@bretg
Copy link
Collaborator

bretg commented Jan 23, 2020

@snapwich - from your last review we updated the openRtb format to support the per-bidder FPD.

@bretg bretg removed the needs docs label Jan 23, 2020
@bretg
Copy link
Collaborator

bretg commented Jan 23, 2020

docs PR prebid/prebid.github.io#1764

@msm0504
Copy link
Contributor Author

msm0504 commented Jan 23, 2020

@bretg The prebidServerBidAdapter will handle that case, but the data won't be duplicated within ext.prebid.bidderconfig.

Here's the unit test for the scenario:

it('passes first party data in request', () => {

modules/rubiconBidAdapter.js Show resolved Hide resolved
}

const matchingFpd = find(acc, addedFpd =>
JSON.stringify(addedFpd.config.fpd) === JSON.stringify(fpd));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not a safe comparison. Browser's honor insertion order for objects which means two objects that essentially contain the same data would not be equal depending on the order the data was inserted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the code for setBidderConfig, the data is separated out and stored by bidder. Here I want to combine that so if multiple bidders have the same FPD, the data is only added and sent once with an array of all bidders. How would you suggest checking whether FPD configs match?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you'd have to do a deep comparison if you wanted to be sure that they were actually "equal"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an existing util for deep comparisons? Or would I need to add or write one?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msm0504 - there's this imported in utils.js

export { default as deepAccess } from 'dlv/index';

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is not currently a utility method for doing deep comparison in Prebid.js. I guess my concern is deeper though: why is this API attempting to de-dupe repetitive data? It seems to make for an awkward data structure and I can't see any reasons for the attempt other than space savings? Isn't that what gzip is for?

matchingFpd.bidders.push(bidder);
} else {
acc.push({
bidders: [ bidder ],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason this is an array? It seems like it will always be an array of one bidder.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not always. If 2 bidders have the same FPD, the 2nd will be added to the bidders array

@msm0504 msm0504 removed the needs 2nd review Core module updates require two approvals from the core team label Feb 19, 2020
@msm0504 msm0504 merged commit 3662ee3 into prebid:master Feb 19, 2020
@msm0504 msm0504 deleted the standard-first-party-data branch February 19, 2020 20:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants